      *      *                   *     *                          *
      **     *                   **   **                          *
      * *    *             *     * * * *          *          *    *
      *  *   *   *****  *******  *  *  *   *****  ******  ******* ******
      *   *  *  *     *    *     *     *  *     * *     *    *    *     *
      *    * *  *******    *     *     *  *     * *     *    *    *     *
      *     **  *          *     *     *  *     * *     *    *    *     *
      *      *   ******    *     *     *   *****  *     *    *    *     *
      *                                                                 *
      *             The guide to BITNET servers and services            *
      *                                                                 *
      *  Volume 2  Number 5                              November 1987  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *  Editor:                           Chris Condon  CONDON@YALEVM  *
      *  NetMonth Staff Supervisor:        Gary Moss       MOSS@YALEVM  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *  It was the spring of 1981.  In Manhattan and New Haven a pair  *
      *  of modems were brought to life, and data began to flow over a  *
      *  leased telephone circuit between the computing centers of the  *
      *  City  University  of New York  and  Yale University.  A  bold  *
      *  experiment had begun that over  the next several  years would  *
      *  grow  link  by  link  into  a  worldwide  network of academic  *
      *  computers.  BITNET started with only  a single wire, but with  *
      *  the  inspired  vision of  a  global  community  of  scholars,  *
      *  sharing research, ideas, and  information.  Few  at t he time  *
      *  believed  that  such  a network, based  on cooperation  among  *
      *  academic  institutions,  would  ever  succeed.  At least  two  *
      *  individuals believed that  it would.  Ira H. Fuchs, then vice  *
      *  chancellor for University systems at CUNY, had seen a network  *
      *  within the  IBM Corporation  grow worldwide,  interconnecting  *
      *  not only  programmers  but  researchers  and  managers.  This  *
      *  network, called VNET, spread  among IBM  sites using standard  *
      *  IBM  software  and leased telephone lines, with each new link  *
      *  responsible  for its  connection  to the  network.  Together,  *
      *  Fuchs and Greydon Freeman, then director of the Yale Computer  *
      *  Center,   saw   in   this   model   enormous   potential  for  *
      *  communications  among  institutions   of   higher  education:  *
      *  administrators, faculty, and  even students  could use such a  *
      *  network  to share  information.  Fuchs and Freeman  envsioned  *
      *  more  than  CUNY  and Yale sharing computer data.  Nothing in  *
      *  the  network  software   restricted  the   communications  to  *
      *  computer programs.  Increasingly, universities were beginning  *
      *  to view the computer as a tool for for processing information  *
      *  and text as well as number crunching...                        *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *            From "BITNET: Past, Present, and Future"             *
      *            by Daniel J. Oberst and Sheldon B. Smith             *
      *                                                                 *
       *****************************************************************
1


   *************************************************************************
  * Contents                                                                *
  ***************************************************************************

  Bitnotes ................................................................ 1
  Scuttlebut .............................................................. 2

  FEATURES___________________________________________________________________

  Internet-BITNET Gateways ................................................ 4
  Relay, Bitnic, and Christmas ............................................ 8
  Finding People in Other Networks ....................................... 12

  SERVERS AND SERVICES_______________________________________________________

  A New Name Server: LOOKUP@RITVM ........................................ 13
  New Mailing Lists ...................................................... 14

  DEPARTMENTS________________________________________________________________

  Feedback ............................................................... 17
  Policies ............................................................... 18

  NetMonth is a  network service  publication  distributed free  of charge to
  students and professionals in BITNET and other networks.  This magazine and
  it's  companion  file, BITNET SERVERS, are  the work  of the  Yale Computer
  Center  BITNET  Services  Library  (BITLIB) staff.  The  BITLIB  is a local
  online help  facility designed to  inform  Yale network  users  about  what
  services are available  to them  through BITNET, and  provide  instructions
  and  utilities  for their  proper use.  In publishing  NetMonth  the BITLIB
  staff  members hope  to share the  fruits of their  labor with institutions
  outside of Yale in  order to promote a productive  and enjoyable networking
  environment for everyone. The BITLIB system is now distributed to more than
  thirty educational institutions worldwide.

  BITNET SERVERS is BITNETs  most  complete  and  up-to-date  list of servers
  and services.  It is sent to  NetMonth  subscribers at the same time as the
  magazine.  BITNET SERVERS is dependent  on your support to remain accurate.
  If you know of servers and  services  not  listed  in BITNET SERVERS, or of
  those listed in the file that  are no longer available, please  contact the
  NetMonth staff at BITLIB@YALEVM.

  For information  on  subscribing  to NetMonth  and  BITNET SERVERS, see the
  "Policies" section on the last pages of this issue. Within "Policies" there
  are also instructions for  submitting  articles,  sending  Letters  to  the
  Editor, and printing this file.

  -----------------------------------------------------

  A publication of the Bitnet Services Library          "Because We're Here."
1

                                                                       Page 1


   *************************************************************************
  * Bitnotes                                                       Issue 16 *
  ***************************************************************************


  * And now for something completely different...

  ...and more of  the same.   There  is little  need for me to  repeat what I
  have mentioned too many times before.    BITNET is changing and growing day
  by day, and yet it remains recognizable.   More important,  your needs have
  changed and grown with the network.  NetMonth should reflect those changes.

  NetMonth began as a  weekly list of servers and services  known as Bitlist.
  The need for more in-depth information on this subject became apparent, and
  the current magazine came into being:  "The monthly guide to BITNET servers
  and services."  That caption was a guideline for what should be included in
  each issue.  Now, I offer you a new caption for a new NetMonth:

                     "The independent guide to BITNET"

  How will this new NetMonth differ from the old?  This changed magazine will
  include information on all issues of relevance  to the network,  be it news
  about servers and services, tips for using the network more effectively, or
  editorials by the network users.

  Here are some of the new features I'd like to include:

  1.  A "Question and Answer" section.   I may not know the answer,  but I'll
  find someone who does!

  2.  An "Editorial  Page"  featuring  regular and  irregular columnists from
  different areas of the network, both physical and virtual.

  3. A monthly spotlight on a network outside of BITNET with instructions for
  how to send mail to people there.

  In  order to  achieve  all this  there  is  a catch:    We  will need  your
  contributions more than ever.   We will need questions for the Question and
  Answer section.   We will need writers for the Editorial Page.   Yes, let's
  make it official:

       WANTED:  Bright people with any range of BITNET experience needed
       to  write  monthly  columns   about  any  network-related  topic.
       Applicants  should  posess  at  least  passable  writing  skills.
       Editorials do  not have to be  long ( 1  to 3 pages)  and  may be
       serious, humorous, or anything in between.  People who are unable
       to contribute regularly are welcome  to submit anything they can,
       whenever they are able.  There is no pay, but visibility is high.
1

                                                                       Page 2


  Now,  I know that you are busy people.    However,  if I can find the spare
  time to  put together the  magazine,  couldn't you  find a little  to write
  something?   Many  of you  have a wealth  of information  and understanding
  about the technical  aspects of the network  that I do not  yet understand.
  All of you have a different insight, and contrasting opinions.  This is one
  of the things  that makes BITNET an interesting place  environment in which
  to work and play;  I want to reflect that in NetMonth.

  Also, a question:  What would your  reaction be  to a NetMonth published on
  paper  and  delivered  by  your  postman?  I am,  of course,  speaking of a
  desktop-published  newsletter with  attractive fonts and graphics.  Would a
  format like that make you more or less likely to contribute?

  Next month:  A new format, a new design, a new NetMonth...


   *************************************************************************
  * Scuttlebut                                                              *
  ***************************************************************************


  * Relay at TCSVM shut down:  Wendel Bordelon and John Voigt of TCSVM issued
  the following statement:   "Well - it  has finally happened.   We have shut
  RELAY down.    Reason:   Load on our  system.   Last night We  were getting
  better response from the RELAY at Aggieland than the one here.   There were
  over 140 users  on 57 channels.   Many  of the private channels  had only 1
  user signed on.

  "Recommendation:   Limit number of public channels to 10.   Limit number of
  users per  channel to 6.    Eliminate /m command.   If  you want to  send a
  private message  don't use RELAY  to do it.    It doesn't save  any network
  bandwidth and just causes extra overhead in RELAY.  Limit number of private
  channels.   Allow the same number range (or use names(make Phil happy)) but
  limit how  many can be  created.   Kick off users  on a private  channel by
  themselves at the next clock tick check.

  "If RELAY at TCSVM is to come back  we have to make RELAY something that is
  worthwhile and  useable.   No  one should  have to  live with  the kind  of
  response time that RELAY provides when that  many users are on.   I find it
  very hard to hold a conversation with 19 other users.  That's how many were
  on channel 1 last night.  This has got to be corrected."


  * BITNET-Internet Gateways announced (from  Bitnews):   The City University
  of New York,  Princeton University,  Cornell University,  and Massachusetts
  Institute of Technology have each committed  to provide gateway service for
  electronic mail between the BITNET network and the Internet.
1

                                                                       Page 3


  Current gateway services  provided by the University  of Wisconsin (WISCVM)
  will end on December 15,  1987.   Prior to  that date,  at least two of the
  above announced  gateways will be  in operation  in parallel with  WISCVM -
  there will be no interruption in gateway services.

  Prior  to a  regionalization  plan and  significant  coordination with  the
  Internet,  the most expeditious approach is  to name the first few gateways
  the same, namely, INTERBIT.  That would mean that any gateway-destined mail
  that landed  at any  INTERBIT node would  be appropriately  handled.   This
  change will be  reflected in the December  DOMAIN NAMES file which  is used
  for  MAILER  generation;   users  need  not do  anything  -  mail  will  go
  automatically  to  the closest  gateway.    This  is a  transition  measure
  necessitated  by the  time  frame,  by  the  complexity  of more  desirable
  solutions, and by the need to coordinate more with the Internet.

  Plans are to  regionalize gateway service between the networks  in order to
  balance traffic flow and increase reliability.   Several other institutions
  are  seriously  considering  functioning  as  gateways.    An  analysis  of
  topologically best locations for such gateways  will be conducted under the
  auspices of  the BITNET  Board of Trustees'  Technical Committee;   and the
  BITNET Network Information Center will coordinate regionalization plans and
  associated software modifications.

  See also in this issue: BITNET-Internet Gateways.

  (Please note reference  to Internet,  rather than  ARPANet,  and Internet's
  inclusion of ARPANet,  NSFNet,  NYSERNET  and the other regional networks.)


  * A warning from Malcolm Dickinson:

  There is a self-propagating "virus" exec that has recently been released by
  a grumpy scrooge onto BITNET.  It is called "CHRISTMA EXEC".

  This virus is a sneaky one.  You may find it in your reader, sent to you by
  a friend of yours in BITNET.  If you load it from your reader and then type
  CHRISTMAS, it will draw a little christmas tree on your screen, then SEND A
  COPY OF ITSELF TO EVERY USERID IN YOUR * NAMES fille.

  This may not  seem to be so  malicious,  until one considers  the amount of
  file traffic such an exec can create.   If you have 20 people in your NAMES
  file, and 15 of them run the exec that gets sent to them,  and each of them
  has 20  people in  their NAMES  file,  the  resulting file  traffic on  the
  network will be 320 file transfers.  In the next generation it will be 6400
  files,  and in the next generation,  128,000 files.   If the exec is spread
  thoroughly without a concerted effort to stop it, a few million copies will
  be flying around the net within  a week,  slowing file traffic immeasurably
  and costing thousands of dollars in CPU time.
1

                                                                       Page 4


   *************************************************************************
  * Internet-BITNET Gateways                                                *
  ***************************************************************************

  By Henry Nussbacher and Douglas Bigelow                        from Bitnews


  Much  progress  has  been  made  in  BITNET  toward  establishing  a robust
  interconnection  with the Internet.  The  following  is  a  report  on  the
  current gateway situation. Hopefully  it will provide a stimulus and  focus
  for further short-term and long-term developments.

      Douglas Bigelow
      Chair, BITNET Board of Trustees Technical Committee


  The  removal   of  the  University  of  Wisconsin   BITNET-ARPAnet  gateway
  (WISCVM) on  December 15th, 1987  has caused a  reanalysis  of  the  entire
  gateway  situation in BITNET.  The  Internet (ARPAnet, CSnet, NSFnet, etc.)
  presents a unique problem of  interconnection,  due to its size.  A  single
  gateway,  albeit  a  simple  and   easy  to  implement   solution, presents
  problems of large backlogs and  network  congestion, both to  the  Internet
  and to BITNET. This was proven very clearly with the Wisconsin gateway.

  This paper will detail the "regional gateway" proposal, the  pros  and cons
  of this interim solution and what steps need to be taken in the future.


  I. THE BITNET SOLUTION:

  The  regional  gateway  solution  states  that  every  node  is to use  the
  Internet gateway  closest to them.  The gateway  id  of  SMTP@INTERBIT  has
  been  decided upon  as the universal  gateway id that all BITNET nodes will
  need to  know about.  The steps required  to  implementing  "SMTP@INTERBIT"
  have been:

  a)  register  the node  INTERBIT in EARN,  BITNET,  and  NETNORTH  as being
  connected to node CUNYVM.  This has been done.  As of  December  1st  1987,
  most  nodes have updated  their  tables and therefore know of the existence
  of a node named INTERNET.

  b)  alter the  DOMAIN  NAMES  file  (the  file   that  many  sites  use  to
  customize  their  mailer support to  handle domain  type names) to have all
  Internet traffic sent to  SMTP@INTERBIT  (originally was SMTP@WISCVM). This
  will be released to the public on the week of December 5th.

  c)  have more nodes create  pseudo  nodes  called  INTERBIT. The sites that
  have agreed (so far) to act  as regional  gateways are:  City University of
  New York, MIT,  Princeton University  and Cornell University.  (These  were
  the intiial four;  other serious  offers and inquires continue to come into
1

                                                                       Page 5


  the  BITNIC.)  This  will  be  an  ongoing  process  which  will constantly
  contribute  to  the  equal  distribution  of  Internet  traffic  among  all
  gateways.  As  more  gateways connect, the load on CUNY and the other three
  initial regional  gateways  should be reduced. It is expected  that  within
  one year there will be in excess of 20 regional gateways.

  d)  alter  the  route  table  generation  programs  (in EARN and BITNET) so
  that more nodes make  use of  end-of-path  regional  gateways.  An  example
  would  be MIT, which  has many  high volume neighbors, all of which will be
  initially pointing to CUNY (which is much further away).


  II. POTENTIAL PROBLEMS:

  1)  JES2: The JES2  Path Manager attempts to route files  to  any  INTERBIT
  node  it may  know  of. If one is down or not available, then the JES2 Path
  Manager has  no qualms  about routing the data to any other known  INTERBIT
  site.  This  can  cause  network  loops.  The solution to this is to define
  only  the  CUNYVM-INTERBIT  connection  to  all  JES2  sites   and  not  to
  elaborate the alternate connections.

  2)  Loops: Each  site receives a customized route table from BITNET's Chris
  Thomas or EARN's NETSERV GENROUTS.  Initially, they  will all have INTERBIT
  being  a  node connected to CUNYVM.  But as more and more  INTERBITs become
  available, a  need for  customizing the route tables becomes  more  urgent.
  Imagine the following topology:

                                 X-A-B-C-D-E

  When  "  X"  represents  an INTERBIT  node, then all nodes (A-E) have their
  route tables pointing to A as being  the final  link before  INTERBIT.  But
  if the following were to occur:

                                 X-A-B-C-D-E-X

  then  it would be foolish for nodes D and E to  route  their Internet files
  to A;  but rather they should route their data to E.  In  addition, node  C
  decides  that  it   wishes to  route its Internet traffic to E. That too is
  also valid. But if for some  reason node  D changes its routing from  E  to
  A, then there will be a loop between C  and D.  It is imperative then, that
  all  nodes  be  warned  that  they  are  not to  tamper with the routing of
  INTERBIT in their customized route tables.  If a  node has complaints about
  an INTERBIT site (rejects valid  BSMTP mail,  garbles  headers,  is  always
  down  for maintenance, etc.) and  these  complaints are justified, then the
  INTERBIT gateway in question will be  removed from  the routing tables  and
  all  neighboring  sites  will be assigned to another  regional gateway. But
  under no  condition  should a site decide on its own about where  to  route
  INTERBIT traffic.
1

                                                                       Page 6


  Advanced  nodes  that   need  to  alter their routing can change the DOMAIN
  NAMES file to point  away  from   SMTP@INTERBIT  to  some   other  regional
  gateway "true userid" - like SMTP@CUNYVM,  and in that way  bypass the RSCS
  looping problem. In general, the rule should be:

           NEVER ALTER RSCS ROUTES BUT YOU CAN ALTER DOMAIN NAMES


  III. PROPOSED ALTERNATE SOLUTIONS:

  Customized  DOMAIN NAMES:  This  solution  would  work if every node used a
  mailer and the DOMAIN NAMES file.  Unfortunately, there  are many sites out
  in  BITNET,  who have only the time  to update  their RSCS route tables and
  do not wish to be bothered  with another  set of tables  to  be  updated  -
  namely  mailer  tables.  These  sites will just latch on to the most common
  gateway  available to  replace WISCVM, which in  all  probability  will  be
  CUNYVM.  This  will  put  a  large  strain  on CUNYVM - one that  it is not
  prepared to handle.  Even if these sites could be convinced to  route their
  Internet traffic to  some site other  than CUNY, we run  into  the  problem
  two  years  from now, when  there will  be 50 or even 100 regional gateways
  and these "small" sites  will still  be pointing to one of the  4  original
  regional  gateways.   The method  described in the Solution section, solves
  this problem of the "lazy" node.


  IV. THE INTERNET SOLUTION:

  Now that we understand  what  needs to  be  accomplished  from  the  BITNET
  side,  we  need  to  also analyze  what  needs to be done from the Internet
  side of the network.  Mail originating in  BITNET, that is  sent  into  the
  Internet, will have  the  RFC822 headers altered by the gateway to indicate
  which  gateway  has  processed   the  mail.   Therefore,  the  user  in the
  Internet will have a valid header  which  will point  back  to  the  BITNET
  regional  gateway  and  from  there  to  the  destination  user. Example:

                    user%TUCC.BITNET@VM.PRINCETON.EDU

  The more  major problem  comes about when a user in the Internet wishes  to
  originate  mail  to  a  BITNET user.  Here, once  again, there are multiple
  solutions:

  1)  On your own:  Each  site or each user  will have  to  decide on his/her
  own  which regional gateway  to use.  They  might  just  hardcode  a  known
  regional  gateway  into their  mail  software and from then on, all traffic
  from that  Internet node  will flow via that stated node.  This is  not  an
  optimal  solution  but  it  is  one  that  works.  TCP/IP does not have the
  problem with network  loops that  RSCS has, so users  user  can  decide  on
  their own which gateway is best for them.
1

                                                                       Page 7


  2)  Create a BIT.NET domain:  This is  similar in concept  to the  INTERBIT
  generic  nodename.  The user in the Internet would  type in  a user address
  like:

                             user@GWUVM.BIT.NET or
                           user%VAX.OX.AC.UK@BIT.NET

  and the  Internet  software would determine which gateway is closest via MX
  records.  This  approach  has  had  a  mixed  response  from  the  ARPAnet.
  However,  most   network  people  seem to agree that the following solution
  (3) is the one toward which we should all work.

  3)  Register all BITNET domains  in the Internet:  This should actually  be
  viewed  as  a  long  term  solution  for  the  merging  of  BITNET  and the
  Internet.  The problem  with this is that every institution that wishes  to
  be  registered  in  the Internet,  needs to have i ts own "house" in order.
  That means that each institution  needs complete  domain  support  covering
  ALL  nodes  at that institution.  If a few nodes at the institution are not
  supported  via domains  locally or if  there  are  two  or  three  seperate
  Ethernets that do not  communicate one  to the other, then the registration
  of  a  domain type name in  the Internet  will not solve these problems but
  rather compound them.

  Once all  sites are  registered  with  SRI,  then  mail  flowing  from  the
  Internet  can determine  how to send  it via the domain name server. If the
  site has a direct  connection to the  Internet, then  the  data  will  flow
  through  the  Internet  until  it reaches  the correct gateway. If the site
  does  not have a connection  to the Internet, then the data will be pointed
  to one  of the  numerous regional gateways which will move the file over to
  BITNET and from there the file will be delivered via Mailer or BSMTP.

  For this  solution to be  most effective, all  BITNET  institutions  should
  support  domain-style  names  for  all their nodes.  The RSCS nodename will
  become the equivalent of an IP  address,  and  the  dotted  domain  address
  will be transparent whether it originated in NSFnet, ARPAnet or BITNET.

       Henry Nussbacher

            _______-----___--______________________________________
            ____------------------_________________________________
            _-----__-----------------______________________________
            ---____----__---_----_-----____________=======_________
            -_____---___----_----___----________=============______
            ______-____----____--_____---______===============_____
            _________----________-_______-_____===============_____
            _______----_________________________=============______
            ______----_____________________________=======_________
            ____----_______________________________________________
            __-----________________________________________________
1

                                                                       Page 8


   *************************************************************************
  * Relay, Bitnic, and Christmas                                            *
  ***************************************************************************

  from the RELAY-L list


  Date:         Tue, 01 Dec 87 12:11:49 EST
  From:         Valdis Kletnieks

  Dear fellow Relay Operators:

  Due to  recent events,  I  find it in the  network's best interests  to (at
  least temporarily)  shut  down RELAY@CLVM (the Twilite_Zne).   It  is not a
  decision that is coming easily to me.

  The basic problems are as follows:

  (1)  When I posted my note about  file queues last night,  the file backlog
  was not high.   By the time Gary Moss got it,  the queue at YaleVM was 450.
  As of noon EST today, it is 680 and climbing.  (update:  It is now 12:30EST
  and 760 files  are queued).   This is  reportedly due to a  gateway at MIT.
  Why it is doing it, and what is being done, I have not the slightlest clue.

  (2)  Relay@BITNIC has been quiesced for 3  days.   The Relay-L list was NOT
  told why.   This is about par for the course.   Those who have been on this
  list for a long time have seen me repeatedly flame about this point.   (How
  long does it TAKE  to send a note that says:   "We've  got a rogue gateway,
  we're loaded with files, we're shutting down till it's fixed.."?)

  (3)  I have been hit with a sudden  rash of weenies,  a good number of whom
  should know  better.   The people involved  know who they are...    I won't
  comment any more on this point.

  (4)  The  end of the  semester is coming.    We will  be beseiged by  a CPU
  crunch.  This is an immutable fact.

  I  cannot justify  the CPU  resources for  RELAY if  the only  place I  can
  reliably link  to is  YaleVM,  and when  our CPU is  loaded,  and  when the
  network is so overloaded, and the information (mostly idle chatting) is not
  of an urgent nature.  When push comes to shove, something must give.  RELAY
  is currently one of the lower-priority Bitnet services.

  Zone is NOT being shut down because of a CPU problem.   Although we DO have
  a slight problem with cycles, management is willing to overlook RELAY's CPU
  use during the off-prime time if it is not TOO outrageous.

  The reason I pulled  RELAY was because I see it as NOT  worth the effort if
  all it will talk to is the Yale relay.
1

                                                                       Page 9


  It  will be  restored to  service as  soon  as it  is feasible  to have  it
  connected to the rest of the Relay network.

  Unfortunately,  I do not  see it as surfacing before the  end of next week,
  given the current speed that problems are being resolved.

  Also, I am still debating if I will ever resurrect it unless the problems I
  have with the Bitnic relay are resolved.   I cannot in good faith rely on a
  relay  that  is  (apparently)   arbitrarily  quiesced  without  warning  or
  explanation.   Admittedly, it DOES have to be shut down if there is a large
  queue in a place that it makes a difference.

  However:

  It *should  not* shut  down for  files coming  TO cunyvm  from yalevm  - it
  should still come up and connect Europe  and the rest of the US.   Shutting
  down to offload  the link is Yale's  problem in this case.    Gary Moss was
  nice enough to send a note saying what was done and why.

  It *should* be announced why, and on what link the problem is on.

  It *should* be woken up in a timely fashion after the queue is cleared.

  If the  staff at  Bitnic cannot see  fit to  logon at 9PM  and check  if it
  should be  woken up,  they  should assign a  few trusted masterops  class 4
  privs.   Then they can  post a note saying "689 files  queued for Zanzibar.
  Wait till it's under 35 before waking it up".

  The other possibility is that relay at  bitnic either be removed and linked
  around, or have some other topology change.

  To re-iterate:   My problem is not a CPU problem,  it's more a problem with
  the way the net is managed.

  Amazingly enough,  I still have enough management support for RELAY that it
  will not  be going  away.   If  at some  time in  the future,   the network
  improves, I will bring RELAY back online.

  (End factual discussion, begin political commentary....)

  When it first started out, BitNet looked like a great idea.   Yesterday was
  the third anniversary of CLVM connecting  to Bitnet.   We were 'node number
  421' according to BITEARN NODES.

  It is  now 3  years later.    1700 more  nodes have  joined on.    This has
  provided an unprecedented ability to  intercommunicate between colleges and
  universities.    However,  some  things have  not  kept up.    We now  have
  internodal war about 'Bitnic vs EARN tools'.   A failing link can cut off a
  lot more  nodes than  it used to.    Gateways are  folding under  the load.
1

                                                                      Page 10


  Crucial links are running  further and further behind.   I see  5 times the
  nodes connected.   I  do not see 5 times the  infrastructure (redundant and
  higher capacity  links,  support personell,  network  information services,
  network leadership).

  Bitnet is  in a state of  chaos not unlike  Rome of 300AD.   The  empire is
  falling, but the barbarians are not pounding on the door - yet.

  Date:         Fri, 04 Dec 87 11:03:01 EST
  From:         Craig Barefield

  In reply  to Valdis's  last mail  message regarding  his shutting  down his
  Relay, I agree with him 1000% to every point he is making.

  I too am faced with a similar  situation,  and am considering shutting down
  NYU's Relay.    The only difference is  that we connect directly  to Bitnic
  thus when they are quiesced, we are an isolated Relay.

  I am also at  the point where I can no longer  tell the Systems programmers
  at  our lower  level links  (vaxes,  etc.)   not  to write  their own  chat
  machines.   Once that happens, they will in effect be running PUBLIC relay-
  like machines open to message traffic from ANY  NODE and I WON'T be able to
  stop them from doing it.

  I'm sure that will wreak havoc on the network as well as my machine.   Then
  maybe someone will take notice of what's going on.  Then on the other hand,
  I think it was mentioned before that nobody from Cunyvm or Bitnic is on the
  Relay-L list.  Was that true?   Maybe nobody will notice, maybe nobody will
  care.

  Date:         Mon,  7 Dec 87 20:40 EST
  From:         John McMahon

  With  the advent  of  Relay@Bitnic going  into a  permanent  (?)  state  of
  comatose, and the complete lack of response from anyone who has anything to
  do with the control of it, perhaps we should take some sort of action.

  Let's link around Bitnic.  (Ack... Blasphemy)

  What I am proposing  is a test re-link around Bitnic.    My reasons are the
  following:

  a) The file queues at/around Bitnic are nonexistant.   I realize Yale still
  has a bunch of files sitting there,   but they are handling that problem by
  remaining unlinked.

  b) Relay at Bitnic has not come up in several weeks as far as I can tell.

  c) Noone at Bitnic seems to remember that they have a relay.
1

                                                                      Page 11


  I realize Bitnic's importance, and that they often have held life-and-death
  over Relay.  But, are they keeping up their end of the bargain ?   Would we
  expect  the same  kind of  treatment from  the  operators at  Urbana ?   or
  Aggieland ? or TwiliteZne ?

  Date:         Tue, 08 Dec 87 12:36:28 EST
  From:         Peter A. Klein

  I understand the situation that you are  in,  However,  I have a few simple
  questions for you since you have been brave enough to step forward.

  o Is it still the policy of BITNIC not to allow users from other nodes than
  BITNIC and CUNYVM to have privs on service machines at BITNIC?

  o Since no one at BITNIC seems to want  to spend the time to look after the
  relay there, can someone off node look after it?

  I think that most people on this list  would agree that we don't expect the
  people AT Bitnic to run their relay on a  day to day basis but we do expect
  them to be responsible enough to make sure it is logged on and that someone
  else can monitor it and make the appropriate quiesces and wake ups.

  Hence, I would like to make the following proposal.

  1)  Make Jeff  Kell the contact for the  BITNIC relay (if you are  up to it
  Jeff) since he is the person who will live or die if relay screws up.

  2)  Give several currently  trusted master ops class 8 privs  at BITNIC and
  give several regular ops class 4 privs.   The idea behind the class 8 privs
  is  to allow  responsible parties  to  change the  relay's basic  operating
  parameters when things like file queues, etc... come about.  The reason for
  class 4 privs  is to allow less  trusted operators to also  watch after the
  BITNIC relay.  It is my suggestion that two people from each major link off
  of BITNIC  be given these  privs to allow for  link failures and  the like.
  Finally,  these ops should  be chosen by Jeff since again  he is the person
  who will live or die if relay screws up.

  I hope this proposal or something like it is implimented soon.

                  __________________________________________
                 /                                         /[
                /__________________________________________[/
                ]
                ]        ___________________________________
                ]       ]  ]                               /[
                ]       ]  ]_______________________________[/
                ]       ] /
                ]       ]/__________________________________
                ]                                          /[
                ]__________________________________________[/
1

                                                                      Page 12


   *************************************************************************
  * Finding People in BITNET                                                *
  ***************************************************************************


  People ask me questions.   Scattered within the electronic junk mail I will
  find pleas for help, information, and assistance.   However,  the questions
  are not what you would expect.   There are no questions about why the Relay
  is the quiesced today,  or how to use  a particular server,  or how to send
  someone a file.  No, nothing as mundane or commonplace as that.  The Earth-
  shattering question of our times?

           "How can I find out the userid of X at University of Y?"

  Here then, are a number of ways to find the answer on your own:

  1.  Does the node have a local name server?   Not many do, but if so,  your
  search for information should end here.   BITNET SERVERS contains a list of
  name servers,  and BITNET USERHELP contains an explanation of how to access
  them.

  2.  Check the larger name servers:   Some name servers,  such as NETSERV or
  CSNEWS allow people from all over the network to register themselves.   You
  may find the person you are looking for listed here.

  I make it a point to check the CSNEWS Bitnauts List;  it seems to be one of
  the more  popular places  for people  to register  themselves.   If  I were
  searching  for John  Doe  at YALEVM,   I would  send  CSNEWS the  following
  commands:

  VM/CMS:        TELL CSNEWS AT MAINE BIT SEARCH Doe
                 TELL CSNEWS AT MAINE BIT SEARCH YALEVM
  VMS/JNET:      SEND CSNEWS@MAINE BIT SEARCH Doe
                 SEND CSNEWS@MAINE BIT SEARCH YALEVM

  This way I will receive two lists:  One with all the people in the Bitnauts
  list with the name "Doe" (or with "Doe"  as a portion of their name or list
  of interests)   and another lists with the people from YALEVM.   The person
  you are looking for might be listed there.

  At this point there  is a strong temptation to contact  someone on the list
  you just received and  ask them if they know your  friend John Doe.   Well,
  there are MANY people at each node, and the chances of someone you randomly
  contact knowing Mr. Doe are quite slim.   The only thing this strategy will
  accomplish is annoying somebody.  This is NOT proper network behavior.

  3. Reach out and touch someone.  If you know the phone number of the person
  you want to contact,  it may be simpler  to call them and ask "What is your
  userid@node?"  This costs you some money, but saves you some time.
1

                                                                      Page 13


   *************************************************************************
  * The Name server LOOKUP@RITVM                                            *
  ***************************************************************************


  LOOKUP@RITVM is a  name server at Rochester Institute  of Technology.   You
  should send commands to the server via interactive message.  For example:

   VM/CMS:    TELL LOOKUP AT RITVM /HELP
   VAX/VMS:   SEND LOOKUP@RITVM /HELP

  There are  few actual  commands for this  name server.    The text  of your
  message is the search string, although you may add certain qualifiers.  The
  default is to search for a particular userid.  For example:

  TELL  LOOKUP  AT RITVM  POSTMAST  will  return  information on  the  userid
  POSTMAST:

   * POSTMAST Jenny Beaven  Staff 752 ISC - Technical Support

  If you are looking for a specific last name, add the /NAME qualifier:

  TELL LOOKUP AT RITVM BEAVEN/NAME will return all entries with the last name
  of Beaven:

   * JMBSYS   Jenny Beaven  Staff 752 ISC - Technical Support
   * JMBTST   J. M. Beaven  Staff 752 ISC - Technical Support
   * JMB1989  Jenny Beaven  Staff 752 ISC - Technical Support
   * POSTMAST Jenny Beaven  Staff 752 ISC - Technical Support

  The /FNAME qualifier work much the same way:

  TELL LOOKUP AT RITVM JENNY/FNAME will return  all entries with a first name
  of Jenny:

   * JMBSYS   Jenny Beaven  Staff 752 ISC - Technical Support
   * JMB1989  Jenny Beaven  Staff 752 ISC - Technical Support
   * POSTMAST Jenny Beaven  Staff 752 ISC - Technical Support

  The commands /HELP and ? will return a list of commands.



                                   + ] +
                                 *-[[]//-*
                                > +--+--+ <
                                 *-//][[-*
                                   + ] +

1

                                                                      Page 14


   *************************************************************************
  * New Mailing Lists                                                       *
  ***************************************************************************


  386USERS@UDEL.EDU

  A moderated list  for Intel 80386 topics,  including  hardware and software
  questions, reviews, rumors, etc.  Open to owners, users, prospective users,
  and the merely curious.

  You  can request  the  archives be  sent  via  mail by  sending  a note  to
  386USERS-REQUEST.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to 386USERS-REQUEST@UDEL.EDU.

  List Maintainer: James Galvin  
  List Moderator:  Bill Davidsen 


  BIG-LAN@SUVM

  Mailing list for  discussion of issues  in designing and  operating Campus-
  Size  Local Area  Networks,   especially  complex ones  utilizing  multiple
  technologies and supporting multiple protocols.   Topics include repeaters,
  bridges, routers and gateways; how to incorporate smaller Personal-Computer
  type LANs into the  campus-wide LAN;  how to unify the  mail systems,  etc.
  This is an ideal list in which to debate the relative merits of bridges vs.
  routers.

  Archives are available through revised LISTSERV.

  To subscribe,  send  the following command to LISTSERV@SUVM  via message or
  as the first line of a mail file:  SUBSCRIBE BIG-REQ Your_full_name

  Coordinator: John Wobus 


  FINEART 

  List for dissemination of  information on the use of computers  in the Fine
  Arts.  Topics to be included are:

     Computers used in the design of works of art
     Computers used to fabricate works of art
     Computers used within works of art
     Computers used to analyse works of art
1


                                                                      Page 15

  General areas of interest include:

     Computer Animation      Computer Aided Fabrication   Shape Grammars
     Design Rule Systems     Style Simulation             Image Synthesis
     Image Rendering         Interactive Video            Sensory
     Environments

  All requests to  be added to or deleted  from this list,  or  to have files
  distributed, should be sent to the Coordinator.

  Coordinator:  Ray Lauzzana 


  GayNet@ATHENA.MIT.EDU

  A  mailing  list  about  lesbian  and  gay  concerns  on  college  campuses
  including, but not limited to,  outreach programs,  political action,  AIDS
  education, dealing with school administrations,  social programs,  and just
  finding out  what other  support and  social groups  are doing.   IItems of
  general gay/lesbian interest are also welcome.

  Requests to be added or deleted from this list, problems, questions,  etc.,
  should be sent to gaynet-request@ATHENA.MIT.EDU.

  The list is not moderated.


  IDX3000@SUVM

  Mailing list for discussion of the IDX-3000  Data PBX (manufactured by M/A-
  COM Linkabit).  Topics include good news and bad.

  Archives are available through revised LISTSERV.

  To subscribe,  send  the following command to LISTSERV@SUVM  via message or
  the the first line of a mail file:  SUBSCRIBE BIG-REQ Your_full_name

  Coordinator: John Wobus 


  INFO-CELERITY@DOLPHIN.BU.EDU

  Discussions  pertaining   to  superminicomputer  systems   manufactured  by
  Celerity.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to INFO-CELERITY-REQUEST@DOLPHIN.BU.EDU.

  Coordinator: Glenn Bresnahan 
1

                                                                      Page 16


  INFO-MINIX@UDEL.EDU

  Mailing list for the discussion of the Minix Operating System:  a Version 7
  Unix   clone   written  for   IBM   Compatible   PCs  by   Andy   Tanenbaum
  (minix@vu44.uucp or minix@CS.VU.NL).

  This list is gatewayed to the BITNET  list MINIX-L@NDSUVM1 which in turn is
  gatewayed to the USENET newsgroup comp.os.minix.

  Archives are available by request from INFO-MINIX-REQUEST.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to INFO-MINIX-REQUEST@UDEL.EDU.

  List Maintainer: James Galvin 


  mail.interleaf 

  Discussions on all aspects related to the Interleaf publishing environment,
  including (but not restricted to) the Interleaf language, user environment,
  implementations on new platforms,  user written enhancements,  and filters,
  bug reports and workarounds.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to leaf-request@TEKSCE.SCE.TEK.COM

  Coordinator: Pete Lancashire 


  ORGCHE-L

  Organic Chemistry mailing  list.   To facilitate the  interchange of ideas,
  information, computer programs, papers, to announce opportunities for doing
  collaborative  efforts  (teaching  and/or   research  activities)   between
  specialists in Organic Chemistry and related areas.

  To subscribe to the list send an  interactive message or mail file with the
  following command to LISTSERV@RPICICGE:  SUBS ORGCHE-L Your_Real_Name

  Coordinator: Asuncion Valles 


  SQLINFO%UICVMBITNET@WISCVM.WISC.EDU

  Mailing list for discussions about SQL/DS and general database topics.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to INFO@UICVM.

  Coordinator: Glori A. Chadwick 
1

                                                                       Page 17


  STAMPS@QUEENS

  Discussions  concerning  philatelic  matters  of  all  kinds,   new  issues
  announcements, and news items.

  Coordinator: Geert K. Marien 


   *************************************************************************
  * Feedback                                                                *
  ***************************************************************************


  Date:     Wed, 25 Nov 1987 10:44 PST
  From:     Gene Hart 
  Subject:  Netmonth suggestions

  Chris,   you certainly won't catch me volunteering to write write something
  for NetMonth (my excuse is that I don't know enough about anything),  but I
  have suggestions:

  1)   An article describing the network of  networks out there would be very
  interesting.   I think that I have a good idea of what BITNET is,  but what
  is Internet and  what is NSFNET?   What is ARPAnet,   CSnet,  DECnet,  etc.
  Clearly this could go on forever.  A very basic piece, just describing what
  some of these networks are (mentioning  gateways only in passing)  could be
  very interesting.

  2)   An  editorial or article on  the gateway problems/discussion  going on
  could be very interesting.   I am  thinking here of discussing the politics
  involved.   Why does WISCVM want to get  out of the posistion?   Why is the
  solution to have regional gateways?

  3)   An article on  gateways which is more technical,  that  is why do some
  only pass a certain kind of mail,   a simple description of TCP or whatever
  this new protocol is called.

  4)   A simple discussion  of why domain names are good  and why they should
  simplify the network.

  5)   A  column I would find  interesting would be to  take a to and  a from
  address each month  and follow that path  of a message and  a reply.   This
  could  start  off simple  (bitnet  to  bitnet)   but  could also  get  into
  interesting  gateway stuff  such  as  that the  return  path  can be  quite
  different that  the to path.    The problem  of ebcdic to  ascii conversion
  changing characters could also be addressed.   For example, I exchange mail
  with  someone  in  Australia  and  I  don't  have  any  idea  what  strange
  contortions my messages have to go through  to get to her.   I realize that
  as  a  network user  I  have  no NEED  to  know,   but  it still  would  be
  interesting.
1

                                                                      Page 18


  I hope that  you find something useful  in these suggestions.   As  you can
  infer from these ideas,  I frequently use bitnet  as a path to get to other
  networks and I assume that many others on  bitnet do as well.   It would be
  of  interest  to many  people  if  NetMonth  devoted  more space  to  other
  networks.

  P.S.   Of  course,  I  need to  add that  I find  NETMONTH very  useful and
  interesting.  Keep up the good work.

  ******

  Thanks for the ideas!  However, I  won't take  any excuses  failure to make
  contributions.  :-)

  ***************************************************************************

  Date: 25 November 1987, 20:44:30 EST
  From: Tim Sly 

  This may not be anything new,  but  we are using the international networks
  to supervise  our exchange  students.   The  university at  Umea in  Sweden
  (Seumdc51)  and Ryerson Polytechnical Institute (Toronto,  Canada)  are the
  only schools of  environmental health in the two  countries.    We exchange
  students in their  respective final years,  and  one of the tasks  they are
  required to carry out is a research project in the health field.

  Supervision  of the  project is  carried out  between the  student and  the
  advisor through  the medium of the  north american and european  networks -
  including the sending of drafts, and revisions.

  The arrangement works  very well,  and if  the time zone 'window'  is taken
  into account, direct interactive 'conversation' proves invaluable.

                            Tim Sly,
                            School of Environmental Health, Ryerson


   *************************************************************************
  * NetMonth Policies                                                       *
  ***************************************************************************

  * Subscribing to NetMonth and BITNET SERVERS:

  VM users can be added to the mailing list by issuing the following command:

      TELL LISTSERV AT MARIST SUBSCRIBE NETMONTH Your_full_name

  VAX/VMS users can subscribe in a similar way:

      SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name
1

                                                                      Page 19


  If you cannot send messages in this way, you can send the following command
  as the first line of a mail file to LISTSERV@MARIST:

      SUBSCRIBE NETMONTH Your_full_name

  Arpanet users may use this method, but must address the mail to:

                           LISTSERV%MARIST.BITNET

  A subscriber  can delete  him/herself  from  the mailing  list  by  sending
  LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command.

  * Letters to the Editor:  If you have questions  or  comments  about BITNET
  or  NetMonth  that  you  would  like  printed  here,  mail  your l etter to
  BITLIB@YALEVM.  Make  sure that you  specify  in  the "Subject:"  header or
  somewhere in the letter that it is for the  NetMonth  letters  column. This
  doesn't mean that your letter will be printed, but it helps.

  * Article Submissions: The only requirements for NetMonth articles are that
  they be informative,  interesting, and  deal with  BITNET  services (or any
  other  good BITNET  related topics).  The  editor  will  inform  you of any
  changes to your writing and will submit them  for your  approval, deadlines
  permitting.  Send your articles to BITLIB@YALEVM.

  * Printing this file:  VM users can print this file by  first copying it to
  NETMONTH LISTING and  then printing  the new file.  This will  allow  page-
  breaks and other formatting to be understood by your printer.

  ---------------------------------------------------------------------------

  A publication of the Bitnet Services Library          "Because We're Here."